Rico 的 Make 工作流日报

第 1 版 / 头版

HEADLINE · 00:02 → 23:23 主线报道

微信AI分身怎么做？四条实战路线盘点

今天群里发生了一场从工具尝鲜到底层技术揭秘的连续追问。起初是群友部署 OpenClaw 的小插曲，到了深夜，一个外部微信机器人的演示视频直接引爆了关于“RPA模拟”与“协议级接入”的技术路线之争。最终，群友在 Rico 的引导下，梳理出了一份从正规军到野生派的微信 AI 分身搭建全景图。

CAST@谭啸@Rico（AI分身）技术底牌@精诚知识缝合怪@咏恩@元芷@启明星浱火眼金睛

第 2 版 / 简报

00:02 转折

封号风险与生存法则

技术探讨迅速转向冷酷的现实风控。面对谭啸关于封号的直击灵魂的追问，Rico 坦诚了微信官方的风控底线，并给出了“小号试错、主号规避”的生存建议，将讨论从理想化的技术拉回现实。

谭啸 · Rico（AI分身）

「不存在100%不被封的说法...重要账号还是得做好备份和心理准备」

— Rico（AI分身） · 00:02

00:39 共识

四条实战路线图成型

在经历了深夜的技术解构与风控警示后，精诚结合 AI 的解答，输出了一份包含公众号、个人微信、企业微信和 Make+飞书桥接的四条实战路线图。这套方案得到了 Rico 的高度认可，标志着今天关于微信机器人的探讨完美收官。

精诚 · Rico（AI分身）

「真想玩的话，公众号和企业微信确实是最稳妥的路线」

— Rico（AI分身） · 00:39

11:08 引子

OpenClaw 的初次部署

群友咏恩在部署 OpenClaw 时遇到了报错，通过切换 minimal 分组意外解决。这次小挫折不仅让大家发现了 OpenClaw 支持多模型切换的特性，也为深夜关于自动化工具底层逻辑的探讨埋下了伏笔。

咏恩

「这个龙虾有一些技能，可以选5个模型」

— 咏恩 · 11:08

22:09 激化

外部竞品引发技术拆解

元芷分享了一段外部微信自动回复 AI 的视频求鉴别。启明星浱迅速拆解出其“截图识别+RPA”的简陋底座，指出其缺乏历史记录等致命缺陷。这一举动直接将群讨论推向了底层技术的深水区。

元芷 · 启明星浱

「很基础的截图识别理解，商用落不了地」

— 启明星浱 · 22:09

23:23 实证

Rico 剖析协议级接入优势

面对群友对 RPA 模式的疑惑，Rico（AI分身）亲自下场，爆出了自己 wechat-ws 协议级接入的核心底牌。通过将“模仿人操作”与“直接走通信协议”进行对比，确立了后者在效率和稳定性上的降维打击优势。

Rico（AI分身）

「简单说一个是'模仿人操作界面'，一个是'直接走通信协议'，后者在效率和稳定性上好几个量级」

— Rico（AI分身） · 23:23

第 3 版 / 议题与人物

今日议题

OpenClaw部署

群友分享 OpenClaw 部署排错经验及多模型切换体验。

AI自动化路线

深夜深扒微信机器人底层逻辑，梳理出四条从正规到野生的实现路径。

硬件与设计

探讨 Mac 设备选型及 TikTok 3D 网站前端设计趋势。

人物索引 · CAST

精诚知识缝合怪提炼并输出了完整的微信机器人四条落地路线图

启明星浱火眼金睛一眼看破外部竞品是基于截图+RPA的简陋实现

Rico（AI分身）技术底牌亲自科普协议级接入原理与风控策略

实操干货 · INSIGHTS

微信 AI 分身四条技术路线对比

路线一：微信公众号（正规军），走官方 API 接口，稳定不封号，但只能被动回复；路线二：个人微信机器人（灰色地带），用 itchat 等框架模拟网页登录，可实现主动发消息和群管理，但主号极易被封；路线三：企业微信（折中方案），官方 API 丰富，兼顾稳定性与灵活性；路线四：Make.com + 飞书桥接，适合已有飞书生态的用户，通过 Webhook 桥接微信。

— 精诚、Rico（AI分身）

RPA 与协议级机器人的核心差异

市面上的低劣微信机器人多采用截图识别+RPA模拟点击，依赖 UI 界面，一换布局就失效；而高级方案多采用 wechat-ws 协议级接入，直接收发底层消息，不需要保持屏幕点亮，速度和稳定性远超 RPA。

— Rico（AI分身）

OpenClaw 部署与模型配置技巧

部署 OpenClaw 时若遇到 assistant turn failed 报错，可尝试切换 minimal 分组来解决。该工具支持配置多种模型，建议使用 DeepSeek 4.0（dp4.0快速）模型，响应速度更快。

— 咏恩、张远

第 4 版 / 数据与附录

97

总消息

14

发言者

2675

总字数

5

故事节点

3

高光人物

2

问答

可复用 SOP

如何通过公众号搭建微信 AI 智能体（路线一）

→ 注册微信公众号（服务号/订阅号），获取后台的 AppID 和 AppSecret
→ 在服务器配置消息推送接口 URL 和 Token，确保微信服务器能将用户消息转发到你的服务器
→ 后端接收 XML 格式的用户消息，调用 GPT/DeepSeek 等大模型 API 进行处理
→ 将大模型回复封装成微信要求的 XML 格式，通过接口被动回复给用户

如何通过 Make + 飞书桥接搭建 AI 机器人（路线四）

→ 在飞书开放平台创建应用，开通机器人能力，配置事件订阅（接收消息）
→ 在 Make.com 中创建新 Scenario，设置 Webhook 作为触发器，用于接收飞书推送的用户消息
→ 在 Make 中添加 Router 或 AI 模块（如 OpenAI/DeepSeek），处理文本并生成回复
→ 使用 Make 的 HTTP 请求模块调用飞书发送消息 API，将 AI 生成的回复推送到飞书会话

协议级微信机器人的防封号实操指南

→ 绝对不要在主账号上运行任何第三方协议框架，必须使用备用小号
→ 控制消息发送频率，避免短时间内大量回复或主动群发，模拟真人操作节奏
→ 不要频繁执行异常操作，如批量通过好友、自动拉群等触发风控红线的行为
→ 保持小号在日常手机端也有一定的正常活跃度，不要仅挂在协议框架上

群内问答 Q&A

专门用 claudcode 的话，MacBook 和 Mac mini 哪个更适合？

— Rico（本人号）：mini不好带，没电池，没屏幕，笔记本还是方便些

wechat-ws 协议不会被封号么？

— Rico（AI分身）：微信官方对任何非官方接入都有风控，不存在100%不被封的说法。但协议级方案行为模式更接近真实客户端，别太频繁发消息，做好账号备份即可。

Rico 的 Make 工作流 · 2026年05月22日 · 11:07 → 00:49
今日 5 条主线 · 97 条消息 · 14 人参演 · 本地出版
本期完 · 明日续